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(57) Abstract 

A method using an open communication 
j network (10) to which retailer server stations 
| (20) and customer stations (30) are connected. 
According to the method, a retailer server station 
generates a payment slip for the planned purchase 
transaction between the retailer and a customer, 
which slip comprises data on the retailer, the 
customer, the purchased item or service and 
the price; the payment slip is transmitted over 
the network to a payment server station (40); 
the payment server automatically checks whether 
the payment of said price is authorised for the 
customer in question, by querying the client's 
personal account set up in the payment server 
for paying small amounts, or, in the case of 
larger amounts, by making a query over a banking 
| network (50) separate from the computer network 

(10); if the payment is authorised, the payment server generates a cash voucher comprising at least 
and the cash voucher is transmitted to the retailer to enable the purchase to go ahead. 




30 

some of the data on the payment slip; 
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Precede" de paiement Electronique permettant d'effectuer des transact! ns liecs 
a I'achat de biens sur un reseau infonnatique 

La presente invention concerne un procEde de paiement electronique 
5 permettant d'effectuer des transactions liees a I'achat de biens offerts par des 
marchands au moyen de services telematiques via un reseau de telecommunication 
infonnatique ouvert sur lequel sont connectes des postes serveurs de marchands et 
des postes clients. 

Par reseau infonnatique ouvert, on entend ici un reseau sur lequel des 
10 particuliers ou des entreprises peuvent librement se connecter a ia condition de 
disposer d'une adrcsse, par exemple le reseau -Internet". Les biens concemes sont 
des produits ou des services, dont la foumiture est realisee hors du reseau apres la 
conclusion de la transaction, ou des biens immateriels, tels que des informations, 
dont la foumiture peut etre realisee via le reseau infonnatique. 
15 Divers proofdes de paiement electronique ont ete proposes, certains 

Etant deja opcrationnels. 

Plusieurs proccdes sont fondes sur une nouvelle representation de la 
monnaie. II s'agit d'une representation electronique, quelquefois denommee "jeton" 
qui peut etre purement logicielle ou partiellement matcrielle, par exemple avec une 

20 carte a puce. Ces procEdes impliquent la circulation de monnaie sur lc reseau 
infonnatique, ce qui pose des problemes difficiles de security vis-a-vis de la 
creation de fausse monnaie. 

D'autres procEdes connus de paiement Electronique impliquent une 
relation directe avec une banque ou un reseau bancaire. Typiquement, de tels 

25 procEdes sont employes dans les reseaux de carte de cnSdit comme, par exemple, 
des procEdes bien connus utilisant des terminaux points de vente relies a un circuit 
carte bancaire ainsi que des procEdes utilisant des cheques tfectroniques avec une 
signature Electronique pour I'authennncation de l'acheteur. Cest une forme de 
lettre d'engagement dmise par un acheteur, remise au vendeur et acceptee et 

30 reconnue par une banque. 

Les procEdes qui impliquent a un moment ou un autre de la transaction 
une relation avec le systeme bancaire traditionnel et la mise en oeuvre d'une 
transaction dans ce systeme piesentent des inconvEnients. Ainsi, les transactions 
dans lc systeme bancaire ont un coat reel qui devient prohibitif lorsque le montant 

35 de I'achat est tres faible, par exemple un montant associe a la consultation d'une 
base de donnees. Or, les reseaux inform atiques sont bien adaptes a la vente de 
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biens de faibl vaieur, principalement dcs bicns d'information, puisque la livraison 
du bien pcut se faire par le reseau lui-meme. En outre, I'acces a un reseau bancaire 
ou un reseau de carte bancaire doit ctre hautement protege, ce qui exdut 
pratiquement la possibility d'un acccs a travers un reseau infonnatique ouvert, tel 

5 que le rcscau "Internet" sur lcquel des acheteurs potentiels pcuvent se connecter. 

L'invention a pour but de fournir un precede permettant d'eviter les 
inconv6nients des precedes connus, en particulier un procedc permettant, sans 
circulation de monnaie electroniquc, de realiser de facon simple et fiable des 
transactions liees a l'achat de biens sur un reseau informatique, et ce aussi bien 

10 pour des biens de prix elev£ necessitant une autorisation par le systeme bancaire 
traditionnel, que pour des bicns de faible ou tres foible prix. 

Ce but est atteint grace a un proedde du type d6fini en tete de la 
presente description et comportant, conformement a l'invention, les 6tapes de : 

- elaboration par un poste serveur de marcband connect* au reseau 
15 d'une demande d'autorisation de transaction, ou "ticket de paiement", concemant 

un achat envisag6 entrc le marchand et un client, et comportant des informations 
relatives au marchand, au client, a l'objet de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau infonnatique a un 
poste serveur de paiement distinct des postes clients et serveurs de marchands, 

20 - verification automatique par le serveur de paiement si le paiement du 

prix est autorise pour le client conceme, la verification 6tant eftectuee, selon le 
montant du prix a payer, soit par interrogation d'un compte propre au client, tenu 
par le serveur de paiement, et destine au paiement des petits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 

25 paiemcnts de montants plus eleves, 

- si la verification est positive, elaboration par le serveur de paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins une partie 
des informations du ticket de paiement, et 

- transmission du bon de caisse au serveur de marchand via le reseau 
30 informatique, afin (fautoriscr la realisation de l'achat. 

Ainsi, le precede selon l'invention est remarquable en ce qu'il 
n'implique ni la creation de monnaie 6lectronique, ni la circulation de monnaie 
electronique sur le reseau infonnatique. 

La gestion des transactions est effectuee par un serveur de paiement 
35 qui seul peut acceder a un reseau bancaire u un reseau de carte bancaire, et qui 
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gere des comptes clients non bancaires sur lesquels des transactions de faibles 
montants pcuvent etrc effectuees. 

Le servcur de paiement gere egalement des comptes marchands non 
bancaires utilises pour les transactions de faibles montants. Ainsi, lorsqu'un bon de 
caisse est transmis apres verification par intenogarion d'un compte client tenu par 
1c serveur de paiement, le montant de l'achat est dibit* du compte client et credit* 
sur un compte marchand propre au marchand concern* et tenu par le serveur de 
paiement, ce qui n'entraine pas des couts de traitement Aleves. 

Chaque client dispose dune identic qui lui est propre pour pouvoir 
utiliser le proc*d* de paiement. II doit Igalement disposer d'un compte bancaire 
reel, de preference un compte utilisable au rooyen du systeme traditionnel des 
cartes bancaires. La verification par le serveur de paiement peut comprendre une 
phase prtalable de validation de I'identite du client a partir du contenu du ticket de 
paiement. La validation de l'identit* est une operation prealable a I'acces eventuel 
au compte du client, si le montant de I'achat est faible, et/ou a I'acces au reseau 
bancaire si le montant est plus elev*. Le serveur de paiement comporte de 
preference des moyens, par exemple une base de donnees, permettant de 
memoriser les relations entre les identites des clients utilisees pour les transactions 
sur le reseau informatique et des identites bancaires (num6ros de comptes 
bancaires ou numeros de cartes de credit) utilisees pour les transactions sur le 
reseau bancaire. On peut cviter de la sorte ia circulation d'identitcs bancaires sur le 
reseau informatique. 

Un mode de realisation de l'invention sera maintenant decrit a litre 
indicatif , mais non iimitatif, en reference aux dessins annexes sur lesquels : 

- la figure 1 est une vue generate ties schematique d'un systeme de 
paiement 6lectronique conforme a l'invention ; 

- la figure 2 est une representation sous forme d'un schema bloc d'un 
serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustre le deroulement des operations relatives a un achat 
30 au moyendu systeme de la figure 1 ;et 

-les figures 4A a 4C sont des organigrammes montrant ties 
schematiquement les operations effectuees par le serveur de paiement. 

Sur la figure 1 est represent* de racon ires schematique un reseau de 
telecommunication informatique 10 sur lequel sont connected des postes scrveurs 
de marchands 20, des postes clients 30 et au m ins un poste serveur de paiement 



20 



25 



35 



40. 
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Le rescau informatiquc 10 est un rescau ouvcit ou public, par exemple 

le reseau denomme "Internet". 

Les scrveurs de marchands 20 sont des unites telles que celles 
couramment utilisees pour des serveurs telematiques connectes sur "Internet", par 
5 exemple des unites organisccs autour de machines "Unix" multiprocesseurs. 

Les postes clients 30 sont essentiellement des micro-ordinatcurs qui 
sont munis de moyens de connexion au reseau "Internet" 10, par exemple sous 
forme d'interface "Web". Us serveurs de marchands 20 ct de postes clients 30 
utilisent par exemple des logiciels connus sous la denomination "Worid Wide 
10 Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, montnS avec plus de details sur la figure 2, 
comprend des unites frontale et dorsale rcspectivement 41 et 42 connectees toutes 
les deux au rescau "Internet" 10. L'unitS frontale 41 a une architecture scmblable a 
celle d'un serveur classique connecte sur un reseau tel qu'"Internct"". Uunit* 
15 dorsale 42 comporte une unite de traitement 43 a un ou plusieuis processeuis, une 
base de donnees 44 comportant des informations relatives aux marchands et clients 
abonnes au systeme de paiement, un registre de transactions 45, une unite 46 
d'interface avee un reseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison similaire pennettant de relier cntrc cux les 
20 differcnts constituants de l'unite dorsale 42. Une liaison securisee 48 pennet une 
communication bidirectionnelle cntrc Kinit* frontale 41 ct l«unit6 de traitement 43. 
La communication avec le reseau informatiquc 10 est controlee par l'unit6 frontale 
41 tandis que la gestion de la base de donnees 44 ainsi que le controle de la 
communication avec le rescau bancaire 50 sont assures par l'unite dorsale 42. 
25 La base de donnees 44 contient des informations relatives aux clients 

et aux marchands abonnes au systeme de paiement. Pour chaquc client, la base de 
donnees 44 contient l'identit6 systeme du client ("CId"), identit6 recue lors de 
l'abonnemcnt au systeme, un comptc de client ou porte monnaie 61ectronique 
("PME") destine au paiement de faibles montants, une identit6 bancaire telle que 
30 numero de compte bancaire reel ou numero de carte de credit ainsi 
qu'eventuellement une clef d'acces ou mot de passe propre au client. Pour chaquc 
marchand, la base de donnees 44 contient I'idcntite systeme du marchand ("Mid"), 
identit6 recue I rs dc l'abonnemcnt au systeme, un compte de marchand, ou tiroir- 
caisse elcctroniquc ("TCE") destind a l'cncaisscmcnt des faibles montants et une 
35 identit ' bancaire t He que numero de comptc bancaire reel. 
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La figure 3 illustie schematiquement les differentes Stapes d'une 
transaction portant sur un achat d'un bicn par un client abonne a un marchand 
abonne. II pcut s'agir d'un bicn materiel dont la livraison au client sera effectuee 
reellement apres conclusion de la transaction ou d'un bien immatenel (tel que de 
5 rinfonnation) qui peut etre foumie au client par lc reseau informatique des le 
paiement llectronique effectue. 

(U Consultation par li> r] 1gn | 

Par connexion sur le reseau "Intemer 10, un client peut consulter en 
ligne le catalogue ou la "vitrine" d'un marchand quelconque par acces au serveur 
10 20 du marchand et par visualisation sur I'ecran du poste client 30 des Mens ou 
services du marchand. Sur presentation de l'idcntit£ CId du client, le serveur du 
marchand peut presenter au client des conditions financieres particulieres (par 
exemple une remise) applicables a la transaction eventuelle. 
(2^ Demande d'arhat 

15 Le choix du client 6tant arrete* sur un bien O, il est transmis au serveur 

du marchand sous forme d'un message contenant une identity Old du bien et 
l'identite CId du client. Lorsque cela est necessaire, par exemple pour la livraison 
ulteneure du bien choisi, des informations complementaires (par exemple une 
adresse et un horaire de livraison pr€fer6). Ccla peut etre realise" de facon 

20 commode en utilisant un formulaire electronique cnvoye sur le reseau et destin6 a 
etre rerapli par le client. 

Dans lc cas ou 1'achat envisage repiesente un montant Sieve" ou est 
soumis a des conditions lcgalcs, une authentificatioo prealable du client peut etre 
soubaiitee. Comme on le vena en detail plus loin 1'authennfication d'un client est 

25 effectuee par le serveur de paiement 40. Aussi, une demande d'authentification 
provenant d'un marchand est emise avantageusement sous la forme d'un ticket de 
paiement de valcur nulle qui est transmis au serveur de paiement par le reseau 
informatique via le poste client et, en cas d'authentification positive, provoque le 
retour d'un bon de caisse du serveur de paiement au serveur marchand, toujours via 

30 le poste client. Les procedures d'&abtisseroent d'un ticket de paiement et de renvoi 
d'un bon de caisse sont decrites plus en detail ci-apres. 

La demande d'achat emise par le client pcut porter sur un seul bien ou 
sur plusieurs biens a fournir de facon groupee : "achat panier". 
(3) Elaboration dc la demande de paiem^r 

35 En reponse a une demande d'achat, le serveur marchand llabore une 

demande de paiement qui pcut comprendre les informations suivantes : 
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- Identity du marchand, ("Mid"); 

_ Description du bien commahde, ou dc chacun dcs biens du panier, en 

cas d'achats groupes; 

- Type de transaction (simple ou panier); 
5 - Identic du client, ("CM"), 

- Identite du bien ou de l'ensemble des biens du panier, ("Old"); 
-Prixdel'objet,("Oid"); 

- TVA (si applicable); 

_ Date et heurc de remission du ticket de paiement (horodatage par le 

10 serveur marchand); 

- Duree de validitd du ticket de paiement; 

- Numcro de serie dans le iegistre des ventes du marchand (notamment 
dans le cas ou la transaction a comporte une etape prealable d'authentification). 

L'ensemble des informations ci-dessus est encodee dans une chaine 
15 d'octets qui constitue la chaine opaque dun ticket de paiement (ou URL de 
commande de bien, URL etant les initiates de "Uniform Resource Locator" ou 
Localisateur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP), comme suit: 

URL http : < SP> < descriptif de la commando , 
20 oil SP est Tadresse "Internet" du serveur de paiement. Le ticket de paiement est 
adresse au poste client. II est complete par deux "ancrcs" logiques qui permettent 
au client soit de l'annuler, soit de le confirmer. 

(d) f |T1 vni de 1'ordm de paiement 

Uordre de paiement est transmis au serveur de paiement simplemcnt 
25 par validation par le client de l'URL de demande de paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transiter par le poste client. 
(S) ^mission du bon de caisse 

Sur reception d*un ordre de paiement, le serveur de paiement 40 le 
decode et precede a l'authentification du client et recherche si le paiement peut etrc 
30 autorise avant de retoumer un bon de caisse ou un refus de paiement. 

Les operations d'authentification de client et d'autorisation de paiement 
seront decrites plus loin en detail en ref6rence a la figure 4. 

Lorsque les verifications effectuees ne permettent pas d'autoriser le 
paiement, une notification de refus motivee est adrcssec au client par 1 serv ur de 
35 paiement (indiquant, par exemple, compte iiisuffisamment approvisionnd, 
depassement d'un seuil autoris6 pour le client, ...) 
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Loisquc les verifications effectuees permcttent d'autoriser Ic paiement, 
les informations contcnues dans le ticket dc paiement sont completees avee un 
numero dc s6ric dans 1c registre des transactions 45, unc cstampillc horaire, unc 
durcc de validiti (typiquemcnt quclqucs dizaincs de secondes) ct Ic sccau du 
scrveur dc paiement constituant une infonnation de certification. L'ensemble de 
ccs informations, Iventuellement apris signature num6rique par l'utilisation dc la 
paitie de clef priv6e d'un systeme dc chifi&ement a clef priv6e/clef publique du 
serveur de paiement (cc qui garantit la validite ct Tintegritc de l'autorisation de 
paiement), est encode dans une chaine d'octets qui constitue la chaine opaque d'un 
bon de caissc ou URLdc livraison : 

URL http : <M> <descriptif du bon de caisse> , 
ou <M> est l'adresse "Internet* du marchand. 

(6) Pan«wtedg livraison 

Lc bon de caisse est transrais au serveur du marchand via le poste 
client. Ceci peut etre effectue automatiquement par le logiciel implante au poste 
client en utilisant la possibilite de re-routage des URL bien connuc dc I'homme du 
metier. Avant d'autoriser la livraison du bien, le serveur du marchand opfcre un 
d6codagc et une verification du bon de caissc regu. Cctte verification consiste a 
utiliser la clef privee eventuelle du serveur de paiement, a verifier que la durec de 
validity n'est pas ecoulee, ct a rapprocher le contenu du bon de caisse avec celui de 
la demande de paiement. 

(7) Livraison du bien 

Lorsque le bon dc caisse est valide par le serveur du marchand, celui- 
ci pcut effectuer la livraison dirocte sur lc poste client, dans le cas dc bien 
d'infonnation, ou adresse au poste client un document pcrmcttant lc rctrait du bien 
et prdcisant notamment le lieu de livraison et le nom du recipiendaire. 

On notera que, dans le cas d'un achat group£ (panier), il y a creation 
par le serveur du marchand d'un objet avec affectation d*une identite unique. Cet 
objet est la liste des URL de chacun des biens du panier. Cest cet objet qui est 
indique dans 1TJRL de commande de bien et qui permettra d'enregistrer le detail 
des biens achet6s dans le registre de transaction du serveur de paiement. 

Les figures 4A a 4C montrent les op6rations effectu6es par le serveur 
de paiement 40 en rfponse a la rteepti n d'un rdrc de paiement. 

Dans l'unit* ftontale 41 (figure 4A), 1'oidre de paiement est d6cod6 
(ctape 61) et sa validite est examinee (test 62) notamment du point de vue de la 
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dure* de validity Si le resultat de l'examen est n6g3tif, une notification de refus est 
envoyee au poste client (tape 63). 

Si le result* de l'examen est positif, il est proced6 ensuite a une 
authentification du client (etape 64), le detail de cette operation tat decrit plus 

5 loin en reference a la figure 4C. Si Identification est negative (test 65), une 
notification de rcfus est envoyee au client (etape 63). Si elle est positive, l'ordre de 
paiement (eventuellement limit* a I'identit* Cld du client, a l'identit* Mid du 
marchand, et au prix) est transmis via la liaison 68 a I'unite dorsalc 42 du serveur 
de paiement reprfsente sur la figure 2 (etape 66). La liaison 48 est une liaison 

10 securisee interdisant l'acces a l'unit* dorsale a toute personne se connectant sur le 
reseau 10. 

L'unit* frontale 41 attend alors que l'unit* dorsale decide d'autoriser ou 
non le paiement (6tape 67). Si le paiement n'est pas autorisi, (test 68), une 
notification de refus est envoyee au poste client (etape 63). Si le paiement est 
15 autorise, un bon de caisse est elabore (etape 69), utilisant les informations 
enregistrees a I'dtape 62. Le bon de caisse est enregistre dans une mdmoire de 
I'unite frontale 41 (*tape 70) et est adrcssc au serveur du marchand via le poste 
client (6tape 71). 

Au niveau de l'unit* dorsale 42 (figure 4B) du serveur de paiement, a la 
20 reception d'un ordre de paiement authentifid, il est examind si celui-ci doit etre 
autoris* a partir du compte client PME via le reseau bancaire 50. A cet effet, le 
prix est compare a un seuil minimum (test 72). Ce seuil est par exemple de 

quelques dizaines dc francs. 

Si le seuil est depasse, une demande pour effectuer roperation de 
25 paiement est lance* sur le reseau bancaire (etape 73) en utilisant l'identite bancaire 
corrcspondant a l'identit* Cld du client, telle qu'ellc ressort de la consultation de la 
base de donnees 44. A la reception de la reponsc positive ou negative (*tape 74), 
celle-ci est transmise a route frontale 41 (*tape 75). 

Si le seuil n'est pas depass*. le paiement peut etre effect^ a partir du 

30 compte PME du client. 

A cet effet, il est examine si le compte est suffisamment approvisionne 
(test 76) Dans la negative, un refus d'autorisation de paiement, e'est-a-dire une 
reponse negative, est renvoyee a I'unite frontale (etape 75). Dans l'affirmative, le 
compte PME du client est debit* du prix et le compte TCE de marchand 

35 correspondant a I'idcntitd Mid est credit* du meme montant (etape 77), la 
transaction est inscrite dans le registre des transact! ns 45 (etape 78) et 
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I'autorisation de paiement, c'est-a-dire unc reponse positive est transmise a l'unit£ 
fiontale 41 avec I'indication du numero de serie de l'inscription dans le registrc de 
transactions (etape 75). 

La procedure d'authentification dans le serveur de paiement (figure 
5 4Q, a l'etape 64 de la figure 4A, comprend l'envoi au poste client, de preference 
dans unc forme securisec (chiffxee), d'une demande de cl6 d'acces, ou mot de passe 
(etape 641). A la reception securisec de la c!6 d'acces (etape 642), une comparaison 
est effectuee avec une information correspondantc contenue dans la base de 
donnees 44 (test 643). 

10 Si la comparaison est negative, et qu'un nombre maximum de 

tentatives infructucuses n'a pas ete atteint (test 644), on retoume a l'6tape 641. Si ce 
nombre maximum est atteint, l'absence d'authentification est constatee, une aleite 
est produite (etape 645) et une reponse negative est envoyee au poste client (etape 
646). L'alerte peut consister en une annulation du compte PME ou en one 

15 surveillance de celui-ci afin de detecter dc nouvelles tentatives d'utilisation. Si le 
test a Tetape 643 est positif, l'authentification est enrcgistrce (dtape 647) et une 
reponse positive est claboree (etape 648). 

Dcs techniques de chiffrcment permettant la transmission securisec 
d'informations numeriques sur reseau informatique, notamment pour la demande 

20 d'envoi de de d'acces et ('envoi de cellc-ci, sont bien connues. 

La procedure d'authentification decrit ici permet d'effectuer une 
authentification prealable d un client dans le cas ou celle-ci est nccessaire avant 
1'etablissement d'une demande de paiement par le serveur du marchand. Pour cette 
authentification, il suffit alors en effet de creer un ticket de paiement dans lequel le 

25 prix indique est nul, comme indiqu6 plus haut. 

L'cnrcgistremcnt dcs bons de caisse dans l'unit6 frontale permet aux 
clients et aux marchands de proctdcr a des contrdlcs et d'en obtenir eventueUement 
des copies. L'enregistrement des transactions dans l'unite" dorsale permet d'en 
conserver une trace en cas, par exemple, de contestation cntrc un client et un 

30 marchand. 

Les comptes clients PME gcres par le serveur de paiement ont cn 
principe un montant de solde plafonnd et, selon le mode de realisation pr6fere de 
1'invenrion, ils nc sont pas rcmun6res (ic systeme de paiement se trouvant en 
dehors du mondc bancaire). Un reapprovisionnement de son compte PME par un 
35 client peut etre effectue a partir de son compte bancaire, par ordre donnd a son 
ctablissemcnt bancaire. 
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Lcs comptes marchands TCE g6res par le serveur dc paiement sont 
assocics a des comptes baneaires reels des marchands dans lesquels ils sont vides 
par exemple quotidiennement. 

Bien que Ton ait decrit ci-avant un mode de mise en oeuvre d'un 
5 procede selon l'invention dans un environnement "Internet" et avec des logiciels 
WWW utilisant le protocole HTTP, l'homme de l'art corapiendra aiseraent que le 
procede peut etre mis en oeuvre avec un reseau informatique autre qu'"Inteniet" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des precedes d'authentification securises mettant en jeu 
10 des dispositife materiels tels que lecteur de carte a puce ou moyen dc 
reconnaissance d'emprcintc vocale pourront etre prevus a la place de clefs d'acccs. 
Ccs demicres et d'autre modifications qui viendront a Tesprit du l'homme du metier 
sont comprises dans la philosophic et la portee de la presente invention. 
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REVENDICATIONS 

1. Pioc6d£ de paicment electronique pour des transactions Hies a l'achat 

dc bicns offcrts par dcs marchands a dcs clients via un r6seau infoimatiquc ouvert 
sur Icqucl sont connect^ des posies serveurs dc marchands et des posies clients, 
5 caracterise par les etapes de : 

- elaboration par un poste scrveur de marchand connects au reseau 
d'une demande d'autorisation de transaction, ou ticket de paiement, conceniant un 
achat envisage entrc le marchand et un client, et comportant des informations 
relatives au marchand, au client, a I'objet de l'achat et a son prix, 

10 " transmission du ticket de paiement via le icseau infonnatique a un 

scrveur de paiement distinct des postes clients et serveurs de marchands, 

- verification automatique par le scrveur dc paiement si le paiement du 
prix est autorise pour le client concerne, la verification etant effectuee, scion le 
montant du prix a payer, soit par interrogation d'un compte client propre au client, 

15 tenu par le scrveur dc paiement, et destine au paiement dcs petits montants, soit par 
interrogation sur un reseau bancairc independant du iiseau infonnatique, pour les 
paiements de montants plus 61ev6s, 

- si la verification est positive, Elaboration par le serveur de paiement 
d'une autorisation de transaction ou bon de caissc comportant au moins une partie 

20 dcs informations du ticket de paicment, et 

- transmission du bon dc caisse au scrveur de marchand via le reseau 
infonnatique, afin d'autoriser la realisation de l'achat. 

2. Precede scion la revendication 1, caracterise en ce que lorsqu'un bon 
de caissc est transmis aprfcs verification par interrogation d'un compte client tenu 

25 par le serveur dc paicment, le montant de l'achat est dibit* du compte client et 
erudite sur un compte marchand propre au marchand concerne et tenu par le 
serveur de paiement. 

3. Precede scion Tune quclconque des rcvendications 1 et 2, caracterise 
en ce que la verification par le scrveur de paiement comprend une phase prfalable 

30 d'authentification du client. 

4. Precede selon la revendication 3, caracterise en ce que 
I'authcntification est r€alisee par reconnaissance d'unc clef d'accfes transmise par le 
reseau infonnatique du poste client au serveur de paiement. 

5. Precede selon I'une quelconque des rcvendications 1 k 4, caracterise en 
35 ce qu'il comprend riaboration par le serveur de paicment d'un bon de caisse 
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compoitant au moins unc partic dcs informations du ticket dc paiement ct une 
information de certification. 

6. Precede selon Tune quelconque des revendications 1 a 5, caracterise en 
ce qu'il comprcnd la memorisation par le serveur de paiement des transactions 

5 autorisees, par stockage d'au moins une partie du contenu des bons de caisse. 

7. Precede selon Tune quelconque des revendications 1 a 6, caractfrisd en 
ce que le ticket de paiement est transmis du serveur du marchand au serveur dc 
paiement par Pinterm6diaire du poste client. 

8. Procede selon Tune quelconque des revendications 1 a 7, caracterise en 
10 ce que le bon de caisse est transmis du serveur de paiement au serveur du 

marchand par l'intermediaire du poste client. 

9. Systeme de paiement electronique pour effectuer des transactions H6es 
a l'achat de biens offerts par des marchands a des clients via un reseau informatique 
ouvert, le systeme comportant des postes clients et dcs postes serveurs dc 

15 marchands pouvant ctrc connect cs sur le rdseau ouvert, 

systeme caracterise en ce qu'il comporte en outre au moins un poste serveur de 
paiement distinct des postes clients et serveurs de marchands et comprenant : 

- une unit£ frontale munie de moyens de connexion au r&eau ouvert, 
-une unite dorsale munie de moyens de connexion a un reseau 

20 bancairc independant du reseau ouvert, 

- des moyens de communication cntrc les unites frontale et dorsale, 

- des moyens de memorisation de comptes de clients, de comptes de 
fournisseurs, et 

- des moyens de traitement pour, en reponse k la reception par l'unit6 
25 frontale d'une demande d'autorisation de transaction ou ticket de paiement, 

concernant un achat envisage entre un marchand et un client, verifier si le paiement 
du prix est autorise pour le client concert par interrogation du compte du client 
ou du reseau bancairc et, si la verification est positive, eiaborer une autorisation de 
transaction, ou bon de caisse afin de la transmettre sur le reseau ouvert via Tunitd 
30 frontale. 

10. Systeme de paiement selon la revendication 9, caracterise en ce que le 

serveur de paiement comprcnd des moyens de memorisation des transactions 
autorisees. 
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